Skip to content

Localize numbers server-side (maintainers' opinion requested) #21770

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 3 commits into from
Closed

Localize numbers server-side (maintainers' opinion requested) #21770

wants to merge 3 commits into from

Conversation

yardenshoham
Copy link
Member

@yardenshoham yardenshoham commented Nov 10, 2022 •
edited
Loading

This one started when I encountered #12637. I wrote RenderNumber in b9319f9 to format the number of commits, then I thought "Why not format all other numbers in a nice way?". So I did it in c929ad2.

While running a search for numbers in templates I encountered JsPrettyNumber and CountFmt. JsPrettyNumber seems to localize the numbers client-side (therefore with a "flash of unstyled content") and CountFmt does it server-side disregarding the user's locale. So this PR can go a few ways:

  1. Land RenderNumber + use it in the places of c929ad2 (current PR state)
  2. Do 1 + refactor the codebase to use only RenderNumber and drop JsPrettyNumber and CountFmt
  3. Drop everything I did and just use JsPrettyNumber for number of commits

What do you prefer?

@yardenshoham
Add RenderNumber
b9319f9 
Signed-off-by: Yarden Shoham <[email protected]>
@yardenshoham
Use RenderNumber
c929ad2 
Signed-off-by: Yarden Shoham <[email protected]>
@yardenshoham
Reorder imports
0aa54f2 
Signed-off-by: Yarden Shoham <[email protected]>
@delvh
Copy link
Member

delvh commented Nov 10, 2022 •
edited
Loading

I don't think we can drop CountFmt as that suffixes with k/ M/ G, and I don't want to have for example 7,654,321B instead of 7.6MB but perfectly localized.
Then, in favor of pure JS side rendering is that it knows best how to format a number for the user.
Against the JS solution speaks especially that it needs JS, and a bit of frontend time, which is especially bad for users with bad hardware or users that disable JS.

Hmm, I don't think that is a strong enough argument not to push the work to the frontend.
So I'm probably in favor of rendering all numbers (where possible) in the frontend.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Nov 10, 2022
@yardenshoham
Copy link
Member Author

yardenshoham commented Nov 10, 2022 •
edited
Loading

Thanks @delvh, looks like a vote for option 3

@lunny
Copy link
Member

lunny commented Nov 11, 2022

The frontend language should not always follow web browser, it's a default option. And users could set their prefer language which maybe different from web browser. And for a more complicated example, users' prefer location and language should become two options, but I think we currently can hold only one.

@6543
Copy link
Member

6543 commented Nov 12, 2022

I think that's a frontend concern and should be in JS code ...

@yardenshoham
Copy link
Member Author

Option 3 decided then, thank you all

@yardenshoham
Copy link
Member Author

Continued in #21786

@yardenshoham yardenshoham deleted the render-number branch November 12, 2022 16:36
@6543
Copy link
Member

6543 commented Nov 12, 2022

still thanks ❤️

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@yardenshoham @delvh @lunny @6543 @GiteaBot